Field of the Invention
The present invention relates to a method for generating a configuration for a control unit test system with hardware components connected thereto, wherein control units can be tested with the test system in an environment simulated by the test system by means of a model, and wherein the test system comprises at least one computer, in particular a computer executing the model, as well as hardware components, that are connected to one another by means of at least one network.
Description of the Background Art
Test systems for performing control unit tests are known in the prior art. For example, control units for motor vehicles can be tested, as well as control units for other devices such as, e.g., automated production equipment such as robots, or even for other transport means, as for example airplanes. All of these devices have largely in common that they have at least one control unit to be tested that acquires environmental data, or data from sensors interacting with the environment, and responds thereto.
In order to verify the (error-free) functioning of control units, a method is used that is also called “hardware-in-the-loop” and in essence dictates that an actual existing electronic control unit is tested, for which purpose this control unit is integrated into a test system that includes at least one computer that simulates a test environment, for example with the aid of a model that is stored and executed therein, and also includes additional hardware components that are connected to one another for the purpose of communication, which can take place, for example, via at least one network, in particular a network designed as a bus.
Examples of typical hardware components, which include the control unit to be tested itself, could be cable harnesses, mechatronic components, actual loads, as well as other electronics required to perform an individual test, for example ND converters, interfaces, etc.
Especially by means of actual loads, it is possible to take into account that under some conditions in a test that is to be performed certain environmental conditions, such as external influences on a control unit, may not be provided by a model in a simulation; consequently, in such a case actual, real loads are connected to the test system, for example actuators, sensors, or other data generators, especially actual hardware components of a system into which a control unit is incorporated for its later operation.
One concrete example from the motor vehicle field is the attachment of a throttle valve to the test system, since this component exhibits a behavior that is difficult to impossible to capture in simulation. Other actual loads, such as a steering system or a gas, brake, or clutch pedal, for example, can likewise be connected, even if they can be simulated in principle.
A concrete test can provide, for example, that the inputs of a control unit are simulated with sensor data from a model, or alternatively, if such sensor data cannot be obtained from a model by simulation, are simulated through data from the aforementioned real components.
The reaction to such data by a control unit to be tested can be accomplished by reading back output data of the control unit into the model or the computer executing the model and can thus be checked, which is to say tested. It is an advantage that such a test system can simulate an environment for the control unit to be tested essentially in real time, so that the control unit can be tested as though it were actually installed in the device in which it is intended to be used later. In order to permit real time capability, simulation cycles can have a preferred duration of less than 1 ms.
Potential errors in a control unit can be detected early by means of such a test system, in particular can be reproduced through repetitive simulation sequences, and the correction of discovered errors can be verified, in particular through repetition of the test sequences that led to the error.
It is critical to the error-free function of a test system that the configuration of the test system has also been performed correctly. Such a configuration, which is to say the assembling of the individual hardware components of the test system and the incorporation of such hardware components in a model to be executed, is performed largely manually, with the result that susceptibility to errors of the test system, in particular the model executed therein, also results from incorrect hardware components being used in a programmed model during configuration, or from an incorrect model, or at least an incorrectly configured or parameterized model for the given hardware components, being assembled or programmed.
For example, if a certain test, which is to say a certain environmental condition or interaction of a control unit with the simulated environment, is to be tested, an error can be caused simply by the fact that a model is used in the simulation that expects data that are not provided by the hardware components, or that processes these data in a manner that is not appropriate for the applicable hardware components.
For example, if a throttle valve controller for a 6-cylinder engine that is implemented in a control unit is to be tested by means of a test system, it is evident that this test cannot be performed correctly if configuration or parameterization of the model that is employed takes place for a 4-cylinder throttle valve.
The susceptibility to error of a manually configured test system, in particular the configuration or parameterization of the model, can be reduced, for example, if a means is created for communicating the technical requirements that a hardware component places on the test system, and here in particular on the model to be executed, to the test system in an automated manner.